Consumers have a wide variety of email providers to choose from today. These providers use web-based email applications apart from standard protocols, such as POP and IMAP. Some software vendors write applications that provide the consumer with easier accessibility to their email. Some applications reside on a user's desktop and provide users with notifications whenever new email arrives, possibly retrieving the email. Other applications provide alternate access to their email from mobile and similar devices.
Several of the email applications require that the system determine when there is new mail for the user. Some providers (such as Exchange) inherently provide a system for email notification when there is new mail, but most of them do not provide for such notification.
The email applications often use inefficient systems and methods to retrieve new email for the user. Some applications periodically retrieve a list of current messages (polling) and compare this list from this new poll with the list from the previous poll to identify new messages. For example, in the Post Office Protocol (POP), applications store the result of a unique identifier listing (UIDL) command in a poll. In the next poll, the application compares the new UIDL results with the old list to obtain the list of new messages. This can become very inefficient if any user has a large number of messages on the mail server.
This problem is made worse for email applications trying to provide these services for web-based email providers that typically present only a partial view of the messages in one page. For every poll, the applications have to “fire” or deliver several web requests, each request retrieving only one set of the messages. This can become very inefficient. These periodic polls often result in no mail retrieval as there is no new mail present in the mailbox. Retrieving all the unique identifiers (UID's) frequently only to find that there is no new mail is inefficient.
Some systems poll a user's mailbox about every 15 minutes. During the day, most polls come back empty. With current protocols, a polling engine must retrieve the entire list every time it polls the mailbox. For users with over a 1,000 emails in the mailbox, there are tremendous inefficiencies. For each mail protocol, a “connector” exists with appropriate algorithms that access the mailbox, list mail messages, and determine the number of emails.
For POP, this is relatively simple. STAT lists the number of email items and a UIDL provides information for all emails or a specified email. For web-based email not using the http mail protocol, a connector retrieves the web page listing the mail, parses through the html source, and extracts message information. In essence, the connector goes through the same steps that a user would go through to access the mailbox. The connector knows what http address is sent to retrieve the mail listing, and the connector knows the keywords that indicate where the message information is located. Since the mail listing is usually limited to a few items (e.g., 20 emails), the connector sends another web request to display the next page (i.e., the next 20 emails).
For iNotes, as an example, the access method is similar to web mail, and the connector sends out an http request to list mail, and the iNotes server returns data in XML. This makes it easier for the connector to extract mail data since it is more standardized than in web mail. Web mail can also be used in a plurality of protocols: XML, http mail or straight html.
Retrieving this web mail or POP mail can be grossly inefficient. A new polling system and method is required to minimize the time taken to poll. Well-designed protocols like IMAP or Exchange address this directly by allowing people to list only a subset of the emails in a mailbox. This is not the case, however, for POP or web mail.